C-RAN, which can stand for Centralized Radio Access Network, Cloud Radio Access Network, Clean Radio Access Network, Coordinated Radio Access Network, and Collaborative Radio Access Network, is a concept that places most of the processing functions of a cellular radio system in a central location, serviced by open platform cloud-based servers with virtualization capability. Compared to a traditional radio access network (RAN), the C-RAN is expected to significantly reduce the cost of servicing the RAN by raising the computing efficiency and, thus, reducing the overall power consumption, reducing the amount of real estate at the remote cell sites, and reducing the amount of equipment required.
Fronthaul is a term used to refer to the communication network that connects the remote radios to the centralized baseband processing functions. Because of its low cost and its ubiquitousness, the use of Ethernet as the transport mechanism is desired. Standards bodies, including the IEEE 802.1CM, IEEE 1904.3, IEEE 802.1Qbu, IEEE 802.1Qbv and IEEE 802.3br working groups, are currently defining how Ethernet is used in the C-RAN's fronthaul network and the mechanisms that can control and reduce the Ethernet network delay and delay variation for the C-RAN application.
A C-RAN implementation is fraught with some very difficult technological challenges. Three of the most significant challenges for C-RAN implementation are: stringent limitations on the maximum delay of the uplink and downlink communication paths between the radio and the centralized processors; stringent performance bounds on the radio's frequency characteristics; and stringent requirements for measuring the delay of the uplink and downlink communication paths between the radio and the centralized processors.
Delay requirements for fronthaul applications are based in part on a mechanism known as Hybrid Automatic Repeat Request (HARQ), which is used for error detection and correction. Details on how HARQ operates are not relevant to the present disclosure except for the limits that it sets on the round-trip information exchange time. For LTE mobile networks, the allowed time for a round-trip (radio-to-controller+controller-to-radio) HARQ information exchange is 4 ms. How this 4 ms time interval is segmented and allocated in a typical mobile radio network is also not relevant to the present disclosure except for the commonly accepted allocation of 150 μs to 200 μs for the one-way fronthaul network delay. This 150 μs to 200 μs of aggregated delay includes the delay for up to 20 km of optical fiber. Assuming a typical optical propagation time of 5 μs/km, the optical fiber could use 100 μs of this delay, leaving only 50 μs to 100 μs of time for the other functions in the fronthaul network. Some sources of delay in a packetized fronthaul network are discussed below.
The radio's frequency characteristics are controlled by the centralized processing resources. The maximum RMS frequency error at the radio is ±50 ppb from the given reference. It is commonly accepted that the reference clock recovered from the wireline link must have an average frequency error of less than ±16 ppb. The Common Public Radio Interface (CPRI) standard, which is currently used as a constant bitrate (CBR) protocol to carry radio data, requires an RMS frequency error of less than 2 ppb below 300 Hz.
The delay of the uplink and downlink communication paths between the radio and the centralized processors must be measured with a sufficient precision for use in C-RAN implementations. The delay of the communication path between the radio and the centralized processing functions must be known to better than ±65 ns.
Packet networks introduce delay in several common ways, including packet generation, channelized packet multiplexing, packet termination, and storing and forwarding. When a CBR data stream is packetized, enough bytes of the data stream must be first accumulated in order to generate a packet. The delay to generate the packet is affected by both the packet size and the bit rate of the data stream. The delay increases as the packet size grows and as the bit rate of the data stream decreases. In the typical situation where only one client is allocated to a single packet stream, a substantial delay can be incurred on any client as it waits for its packet to be multiplexed onto the aggregated packet stream. Clients of lower priority may be further penalized as they may need to wait for higher priority clients' packets to be sent first.
If there are N clients of equal priority, any client may need to wait N−1 packets before it gets its turn to be put onto the aggregated stream. This wait time can vary depending on the presence or absence of other packet streams and the priority of each packet stream. This variance is known as packet delay variance (PDV). Decreasing the packet sizes in the packet streams will decrease the overall wait time but, because small packets have a higher percentage of overhead bytes, the network becomes less efficient, which is highly undesirable.
At the destination, a packet is fully received and checked for errors before it is terminated and its payload made available for processing. Hence, the larger the packet, the longer it takes to begin processing of the payload.
While transiting through a packet network (e.g. intermediate packet switches), each packet is typically fully received before it is forwarded (a.k.a. store-and-forward). Hence, packet termination, packet generation, and the channelized packet multiplexing delays are typically incurred on each packet at each intermediate transit node.
Cut-through methods, which do not wait for all of the payload within a packet to arrive before generating the packet and do not wait for the entire packet to be received before processing the packet payload, are used in some specialized networks. However, these networks are more difficult to implement and manage and are far less flexible. Error propagation is not well controlled and the client and the packet network are intricately tied together timing-wise to ensure neither will run out of data while executing the cut-through processes. The traffic must be well-behaved and the packet network must never be oversubscribed to take advantage of cut-through delay reduction.
Because of the factors mentioned above, transit of data through a packet network typically takes more time than through a TDM network.
Various solutions for reducing delay in an Ethernet network have been proposed. Some standards based efforts are discussed in the following paragraphs.
In a mechanism proposed by IEEE 802.1Qbu, delay and PDV of high priority (express) traffic is reduced by using frame preemption. High priority traffic can interrupt lower priority (preemptable) traffic. However, if a significant amount of traffic is of the express variety, which is the case for the C-RAN fronthaul application, this mechanism offers little benefit. This mechanism requires new equipment throughout the network.
In a mechanism proposed by IEEE 802.1Qbv, delay and PDV for any class of traffic may be reduced by providing scheduled access to the Ethernet stream. However, if a significant amount of traffic is of the same class, this mechanism offers little benefit. This mechanism requires new equipment throughout the network.
In a mechanism proposed by IEEE 802.3br, delay and PDV is reduced by allowing segmentation of large non-express Ethernet frames into smaller Ethernet frames, which are then reassembled at the destination. This mechanism requires new equipment throughout the network. This mechanism still incurs a minimum delay of 64 bytes per packet segment. So, if there are N clients, the multiplexing wait time can still be as large as (N−1)×64 bytes. Ethernet frames of size less than 128 bytes cannot be preempted and segmented. Packet reassembly still requires the entire packet to be received before it can be terminated and the payload processed. If a significant amount of traffic is of the express class, this mechanism offers little benefit.
The inventors have determined a need for improved methods and systems for using packet networks for transporting CBR data streams, particularly for fronthaul in C-RAN applications.